The standardization and proliferation of devices supporting Internet Protocol version 6 (IETF RFC 2460) has begun to solve fundamental issues with IPv4 networks and the IPv4 protocol design (IETF RFC 791). IPv6's expanded address space provides enough unique addresses to serve the billions of devices currently connected to the Internet with ample address space to spare for other uses.
Extensions to the new standards have been developed to maintain backwards compatibility with IPv4 networks. This provides a way for gateways to allow legacy devices to inter-operate inside IPv6 networks. Gateways in these systems can provide the necessary translations between an external IPv6 network and an internal IPv4 subnetwork. This functionality is a beneficial feature to allow IPv6 networks to be adopted gradually and with limited upfront costs.
Although the primary motivation driving IPv6 adoption is the capacity to uniquely identify all devices and services on the Internet with their own IPv6 addresses, little has been done to take advantage of the full 128-bit IPv6 address space. This is especially true in the context of multi-hop, relayed, proxied, and virtualized IP networks.
A generally accepted encoding practice is to encode an IPv4 address in the last four bytes of the IPv6 address. These so called “IPv4-mapped IPv6 addresses” arbitrarily assign the first 80 bits of the address to zero, the next 16 bits to 1, and the remaining 32 bits to the IPv4 address. As the inventors have realized, and as described herein, the additional address space may be used to provide additional information, e.g., additional routing information, to relaying devices.
In one exemplary application of this capability, it is well known that different components of an integrated service can require different resources in order to handle high workloads. Some components benefit from running on more or faster CPUs, for example; some require large amounts of memory or persistent storage; and others demand faster interfaces to local or remote networks. For this reason, among others, current best practices recommend scaling an integrated service “out” rather than “up”—that is, expanding the service to run across multiple instances, computer systems, clusters, or entire networks or sites.
Despite recent advances in methods of sharing processes and data among multiple computer systems, it remains difficult to share a network connection among multiple such systems functioning as (rather than coordinated by and behind) a single endpoint. One obstacle is the document published by the Internet Engineering Task Force and known to the Internet-operations community as Best Common Practice 38 (BCP 38) or Request for Comment 2827 (RFC 2827), which encourages network operators to filter incoming IP traffic with spoofed, or faked, source addresses. Some spoofed traffic on the Internet comes from misconfigured sites, but most comes from maliciously configured sites spoofing traffic, e.g., as part of a denial-of-service attack. These conditions, and the recommendations of BCP 38, constrain operators from spoofing traffic for other, benign purposes.
Nonetheless, a carefully configured service can spoof traffic it wishes to redirect within its own site, or to another site controlled by its operator, in order to provide a content-relay network for remote resources, including those already served by a content-delivery network, to its client nodes. This allows for better scaling inside a centrally managed IP network. Utilizing the additional IPv6 address space provides a mechanism for building such a system.
To improve the efficiency and adoption of multi-hop networks, support virtualized network functions, and provide a means for scaling large networks in parallel across multiple devices, an improved network layer model is needed. The model described herein includes a better utilization of the IP address space, particularly in IPv6, to better inform routing and configuration of the network. Furthermore, methods to make use of virtual networks and the IP address space are combined with virtual network interfaces or devices to build more dynamic and scalable networks.
In some aspects, the embodiments hereof provide systems, devices, and methods for conveying information and state in IP networks among devices, virtual interfaces, virtual clients, and virtual networks.